% ----------------------------------------------------------------------- %
% Arquivo: nsisgoettingen.tex - CAPITULO 5
% ----------------------------------------------------------------------- %

\chapter{O protocolo NSIS pela Universidade de Goettingen}
\label{c_cap_nsis}

A IETF criou o grupo de trabalho para a criação de normas e definição do
protocolo NSIS. Contudo, exitem pelo menos 3 grupos de trabalho que implementam
o NSIS, sendo duas implementações em C++ (Universidade de Karlsruhe e
Goettingen, ambas na Alemanha) e uma e java (Universidade de Coimbra, Portugal).
O protocolo NTLP NSIS desenvolvido pelo grupo de trabalho do NSIS é conhecido
como o General Internet Signaling Transport (GIST).

Na Universidade de Goettingen, Alemanha, é feita uma implementação do NSIS, o
Free Next Steps In Signaling (FreeNSIS) ou formalmente conhecido como OpenNSIS.
Inicialmente conhecido como OpenNSIS, porém alterado por direitos autorais.
Tendo como integrantes da implementação Xiaoming Fu, Christian Dickmann, Bernd
Schloer, Henning Peters, Ingo Juchem, Niklas Steinleitner, Hannes Tschofenig e
Andreas Westermaier, além de contribuidores.

O grupo de trabalho do FreeNSIS mantém o site
\textit{http://user.informatik.uni-goettingen.de/~nsis/} que disponibiliza
acesso a
notícias, download das versões, informações do time do projeto e resposta a
perguntas frequentes.

A implementação do NSIS pela Universidade de Goettingen, atualmente na versão
0.6.0, suporta algumas aplicações que podem ser oferecidas pelo NSIS, como as
implementações de GIST, NSLP QoS, NAT / FW NSLP e aplicações para teste de
comunicação e reserva. A maioria das aplicações são distribuídas sob a licença
GPL. No entanto, a API entre GIST e as NSLPs é liberado sob a licença LGPL.

Dentre os pacotes do NSIS implementado pela universidade de Goettingen, o
NSIS-QOSD (Servidor de gerenciamento de QoS), NSIS-QOS (Cliente que faz
requisições de QoS), NSIS-PING (análise da rede) e a implementação particular de
NAT/FW NSLP.

No pacote nsis contém arquivos para o desenvolvimento do protocolo, com todos os
códigos fontes, listados nos diretórios, em:
\begin{itemize}
 \item gist: Arquivos do GIST, da máquina de estados (FSM), da API do Gist;
 \item library: O framework, este diretório contém classes comuns e bibliotecas
 \item nslp: O diretório com os arquivos fonte do NSLP, contendo a API, as
aplicações do NSIS e um modelo principal da confecção do NSIS.
 \item applications: aplicações de teste, como o nsis-ping;
 \item bin: diretório com os arquivos binários e o arquivo de configuração
nsis.conf
\end{itemize}

Uma das funções mais importantes é a máquina de estados do protocolo, que
gerencia as mensagens e identifica a sessão da sinalização. Cada nó QNI, QNE e
QNR tem sua máquina de estado e uma não tem ligação direta com a outra. Para
este modelo trataremos os três nós de maneira diferente, quando necessário for.

Conforme apresentado neste trabalho, o NSIS é divido basicamente em duas
camadas, sendo a camada de transporte e a camada de aplicação, com seus
aplicativos. Abriremos a camada de aplicação um pouco mais e a dividiremos em
duas camadas, o protocolo com a comunicação com a camada inferior e as
aplicações que rodam sobre esta.

\begin{figure}[!htpb]
 \centering
 \includegraphics[scale=.5]{figs/API-GIST-NSLP.png}
 \caption{Estrutura de camadas NSIS}
 \label{fig:cap5_api_gist_nslp}
\end{figure}

\section{O NSLP}
Subindo ao topo da arquitetura, mostramos o funcionamento do NSIS de Goettigen a
partir da camada de aplicação até a camada de tranporte. O QoS NSLP é executado
através de um daemon, o nsis, que mantém suporte aplicações do NSIS, que serão
executadas.

Quando executado, o daemon do NSIS, o nsis-qosd fica escutando as mensagens
recebidas a partir da aplicação cliente local nsis-qos e de nós diretamente
ligadas a ele, partir de GIST. Ao receber uma mensagem, cria uma sessão com um
identificador. A cada nova requisição de fluxo recebido, cria um identificador
de sessão, denominado SID (session id) e uma máquina de estados FSM (Finite
State Machine) associada a esta sessão.

Quando geradas, as mensagens a partir do aplicativo cliente nsis-qos são
marcadas para o tipo de mensagem (QUERY ou RESERVE) e para o SID. Este SID
criado é pesquisado e se não for encontrado, é criada uma nova máquina de
estados para esta sessão, relacionando o endereço com o SID, que será único
durante toda a rede.

.........

\section{O GIST}
O GIST, ou General Internet Signalling Transport, assume que outros mecanismos
são responsáveis pelo controle de roteamento dentro da rede. O GIST é um modelo
padrão para a camada de tranporte, que pode ser utilizado com os protocolos de
sinalização como o RSVP e NSIS.

A Implementação do GIST por Goetting consiste principalmente em seis partes:
- Principalmente eventos de loop, baseados nos soquetes de conexão;
- Mensagem de estado de roteamento (MRS);
- Associação de mensagem (MA);
- Maquina de estados (FSM - Finite State Machine)
- Mensagem de análise de composição;
- NSLP API 

A sinalização da aplicação requer um conjunto de regras de gerenciamento de
estado, bem como protocolo de apoio para a troca de mensagens de dados ao longo
do caminho. Vários aspectos deste protocolo de apoio são comuns a todos ou um
grande número de pedidos de sinalização e, portanto, pode ser desenvolvido como
um protocolo comum.
